Certificates are used, for example, for authentication, for checking digital signatures or generally for operational or operative processes in various installations, such as industrial installations or else vehicles for example.
Digital key certificates link information about the identity of the certificate holder to the public key of the certificate holder, wherein the certificate holder can also be a device. In this case, the device certificate links the key to a unique parameter of the device, for example a serial number or MAC address. Device certificates are preferably already provided during production by the manufacturer, and also serve for confirmation of authenticity for the device (so-called manufacturer certificates).
Manufacturer certificates usually have a very long validity period (usually several years), so that the device can use this certificate over its entire period of use, for example as a trust anchor for requesting or creating further certificates for operation. In addition, the (root) certificate of the issuing certification entity or certification authority (CA)—and possibly further intermediate certificates—also has to be valid over a time period of corresponding length.
For operation purposes, the devices are often additionally equipped with further, operative certificates. The operative certificates are usually installed or automatically distributed during engineering (configuration) of the devices and are usually regularly renewed. Key pairs comprising a private and a public key are used to this end, said key pairs preferably being generated in the device itself.
Said key pairs can be matched to specific intended uses such as TLS communication, signatures or encryption, for example by selecting different cryptographic algorithms to those in the manufacturer certificate. In addition or as an alternative to the information provided by the manufacturer, said key pairs can also contain information relating to special tasks of the device in the installation, for example “Router 123”, “Munich railway station, switch 17”, “Heating Controller Room 123”, etc.
Since the private keys, which belong to operative certificates, are used more—and also possibly are cryptographically weaker —, operative certificates usually have a considerably shorter validity period than manufacturer certificates. Therefore, said operative certificates have to be able to be replaced more easily.
In order to create operative certificates, a key pair is generated in the device and the public key is read out—usually in the form of a certificate signing request (CSR). This CSR then has to be transported in an authentic and integrity-protected form to the certification entity (CA). To this end, the CSR may already be additionally signed in the device with the private key of an already existing certificate of the device (the manufacturer certificate in the case of bootstrapping, either also the manufacturer certificate or an existing operative certificate in the case of certificate updating). Further signatures by an engineer's laptop, a local registration authority (RA) and the like can be added for transportation protection. Particular protection of the operative certificate on the way from the CA back to the device is generally not necessary since this is not confidential and authenticity and also integrity are ensured by the signature of the CA contained in the certificate.
If the installation is permanently or at least sporadically connected to the RA of the operator such that they can communicate, checking of the CSRs and installation of the new operative certificate can be carried out automatically or via remote access. Otherwise, several visits to the installation by a service engineer are necessary, initially in order to check the CSR and then, after a certificate has been requested and received from the CA, a further visit in order to transmit the certificate to the device.